LabVIEW Idea Exchange

I've had a chance to use the UTF-8 support in LabVIEW 2026 Q3, and for the most part I love it.

This post documents one of just a handful of headaches I've encountered with it.

Since a given character in UTF-8 has a variable number of bytes depending on its numeric value, it's a bit involved to convert between the number of bytes a string occupies and the number of characters represented.

For example, often you want to know the length of a string in characters rather than its length in bytes.

There are some functions that could benefit from having the ability to toggle "character count" mode, vs. "byte count" mode. Namely:

1. String Length
2. String Subset
3. Replace Substring
4. Search and Replace String
5. Match Pattern (Except it doesn't work with UTF-8 yet)
6. Match Regular Expression
7. Search/Split String

There are probably a couple of additional ones I left out.

For these functions, would it be possible to add a context menu selection, "Character Count", that the user may use to toggle off character count mode?

This is what I envision the option might look like for the String Length node. Note the "abc" visual cue on the function connected to the "Chars" terminal. The Character Count menu item would have a check mark leading the text if Character Count were enabled.

In my first project using it to localize UIs, I had to "roll my own" VIs that work with UTF-8 strings in character counts. For length, I check bits 3-7 of the first byte of a char to determine how many bytes represent it.

Thanks very much,

Jim

Recognition is in order: A huge thanks to NI's developers who finally implemented the UTF-8 support.

I think there was serious discussion about how it would be implemented only two years ago (or was it last year?) at GDevCon NA.

It was a very quick turnaround considering how much had to be done to support it, especially in all of the myriad properties and methods of controls.

For the most part, everything just works, and I wrote my first UI with true natively supported translation.

I would like to revive an idea proposed by matt.baker in January 2017. The idea was declined because it received less than 3 kudos in 3 years.

Specifically, it would be great if LabVIEW programmers were able to view the Dataflow Intermediate Representation (DFIR) of a VI.

For clarity, I am asking for the ability to strictly view the DFIR, not to edit or alter it. Simply viewing the DFIR in a window, perhaps with the ability to save the DFIR diagram as a PNG or PDF file.

For those who might not know, please note that internally NI has long had the ability to view the DFIR of any VI. This idea asks to essentially share the internal viewing tool (or a slimmer, less-fully-featured version of the internal viewing tool) with the LabVIEW community.

Viewing the DFIR would be useful to programmers that:

• Develop high-throughput, high-performance applications where achieving the highest possible performance is the goal.
• Develop small, low-level reusable libraries, including free, open-source VIPM packages. These programmers could use the DFIR as a tool in their arsenal, helping them deliver reusable code with the best possible performance. 
• Are looking to understand the LabVIEW compiler better, to gain intuition into efficient vs. not-efficient LabVIEW coding constructs. An efficient coding construct is one that results in a lean DFIR.

Other programming languages expose their intermediary representations. For example, C# programmers can use tools such as the ILDASM (Intermediate Language DisAssembler) to inspect the .NET IL (Intermediate Language) produced by C#. Source: Intermediate Language (ILDASM & ILASM), Common Intermediate Language - Wikipedia.

Based on brief research (please correct me if I'm wrong), it seems that Java programmers have access to something similar, named the ability to inspect the Java Virtual Machine (JVM) bytecode. There is a useful quote in the JVM bytecode Wikipedia page: "Understanding bytecode and what bytecode is likely to be generated by a Java compiler helps the Java programmer in the same way that knowledge of assembly helps the C or C++ programmer." The LabVIEW DFIR would help LabVIEW programmers in the same way that this quote suggests.

Resources:

• The NI LabVIEW Compiler: Under the Hood article introduces DFIR.
• The LabVIEW Compiler Under the Hood.pptx attached to this forum post provides more details.

The following is an example DFIR diagram presented in slide 24 of the pptx.

Counter-arguments

In a reply to the original idea, AristosQueue mentions that "This is not something we are going to be productizing." and highlights that DFIR diagrams can be large and complex even for simple VIs.

While I fully agree and understand that DFIR diagrams may be complex even for simple VIs, comparing DFIRs from one version of a VI with another could still be a fruitful exercise that helps identify optimisations. For example, let's say the DFIR of A.vi is viewed and saved as a PNG file. The programmer then refactors A.vi while maintaining identical functional behaviour. The programmer then views the new DFIR and visually compares with the initial DFIR (the PNG file). If the DFIR is visually much simpler than before (much fewer graph nodes and connections), there's a good chance that the VI will execute more quickly.

In other words, I fully agree with AristosQueue's thoughts that inspecting, understanding, comparing DFIRs may be a time-consuming activity, and activity that only a small subset of programmers may be interested in. Nevertheless, viewing DFIRs would be valuable to experienced programmers who are looking to understand the compiler better, and to produce more efficient code, sometimes for the benefit of the whole community (reusable VIPM packages).

In general, anything that increases the observability of LabVIEW is welcome, as it enables us (professional LabVIEW programmers) to make better decisions.

Hey there. When you open, save, or otherwise select a file or directory from a dialog, there are a couple of behaviors that LabVIEW sometimes exhibits that I find very tedious:

1. LabVIEW forgets with path you last selected in a given use case, so you have to repeatedly select the same file or directory over and over
2. LabVIEW recalls the last used directory, but that directory isn't specific to the context of what you're doing.

An example of the first annoyance is the Mass Compile dialog. If you want to mass compile adjacent directories that aren't anywhere near your last opened path, you have to go all the way back to that directory again.

I ran into the second annoyance yesterday. I was constantly browsing for VIs and controls in a different directory than my project hierarchy, but also concurrently browsing for .NET Core assemblies in Program Files\dotnet

Repeatedly going back and forth between my project hierarchy and the .NET assembly directory became very, very tedious in short order.

LabVIEW recalled the last directory I'd opened, but it made no distinction between the context of the use case.

This is kind of along the lines of Rolf's post many years ago:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improve-the-file-dialog-default-path-when-saving-new-files/idi-p/1725842#M14728

Another idea somewhere in the Exchange was to have a list of recent paths in the dialog the way TestStand implements the feature. In my opinion, that is probably the easiest implementation that would solve both of the grievances I mentioned.

Thanks for your consideration.

Jim

I would like to revive an idea proposed by matt.baker in January 2017. The idea was declined because it received less than 3 kudos in 3 years.

Specifically, it would be great if LabVIEW programmers were able to inspect the LLVM Intermediate Representation (IR) associated with a VI and/or an EXE. As one possible implementation, LabVIEW could output the LLVM IR associated with a VI to a text file (perhaps saved with the .ll file extension, which seems to be the usual extension for LLVM IR text representation).

If LabVIEW made the LLVM IR available for inspection, LabVIEW programmers could then use existing, non-NI tools to better understand how the LabVIEW compiler works and how to achieve the best possible performance in their LabVIEW applications and/or reuse libraries.

Existing LLVM IR inspection tools include:

• travitch/llvm-tools: A set of tools for visualizing and inspecting LLVM bitcode modules. "This package includes some tools to visualize the LLVM IR. Current visualizations include static call graphs, CFGs, CDGs, dominator trees, and some simple escape graphs. Output formats include most graphviz-supported formats, along with an HTML-based format."
• LLVM Tools – Essential Utilities for IR, Analysis, and Optimization | CompilerSutra

The ethos of this idea - increasing observability of compilation artefacts to enable LabVIEW programmers to make better decisions - is identical to that of an idea posted earlier today: Increase observability: Ability to view Dataflow Intermediate Representation (DFIR). I posted the two ideas separately because, while their end-goal is identical (more observability), they can be implemented independently of each other.

The following diagram explains the LabVIEW compilation process (i.e. the transformations that transform a block diagram into machine code). This diagram originates in slide 19 of the excellent LabVIEW Compiler Under the Hood.pptx attached to this forum post. I annotated the diagram by adding the blue text.

Idea Implementation

I don't know it for a fact, but it's likely that internally NI have extensive tools and techniques for analysing the LLVM output of the LabVIEW compiler. What this idea requests is for some of these tools (perhaps in a lite, less-fully-featured version) be shared with the rest of the LabVIEW community.

Resources

• The NI LabVIEW Compiler: Under the Hood article introduces the role of LLVM in the LabVIEW compilation process.
• The aforementioned pptx provides more details.

I have been working with lots of Diagram Disable Structures lately. Specifically, I have been using Diagram Disable Structures to performance-benchmark various implementations that are functionally equivalent but whose execution time is different.

Currently the only way to enable a Diagram Disable Structure case is to right click the structure and select Enable This Subdiagram from a long right-click menu. This works but is quite slow. I sometimes have to spend more than 1 or 2 seconds to find the option and click on it. This adds up when performing the action dozens or even hundreds of times per day. 

Having a native keyboard shortcut that performs this action would increase productivity.

Summary: The new Manage Trusted Files window is uncancellable or takes a long time to cancel.

Details: I opened a project that had been developed in LabVIEW 2025 Q3 in LabVIEW 2026 Q3 for the first time. This is a large project, it contains several thousand VIs. I opened a simple VI that was part of the project and that depended on From JSON Text.vim (part of the excellent JSONtext VIPM package). The VI had a broken run arrow. The Error Window correctly contained a message explaining that the VI depends on code that hasn't been marked as trusted yet. I think this is all expected and correct behaviour so far.

Next I pressed a button named "Manage Trusted Files..." or similar. This popped up the Manage Trusted Files window. I let the window work for a few minutes, without any visible progress. Realising that due to the project size this operation might take a long time, I decided it's best to cancel and uncheck the "Prevent executing untrusted VIs or loading untrusted executable code files" option located in Tools>Options>Security.

I pressed the Cancel button. I waited around 2 minutes - there was no visible progress. The screenshot below shows what I was seeing after the Cancel button was pressed.

I decided to terminate LabVIEW using Task Manager. This cost me a few minutes, as I now had to re-open (re-load) the large project, which takes a few minutes.

Pressing Cancel should take effect immediately.

For symmetry with other map nodes, add a default value input to "remove from map" whose value is returned if the key is not found.

Because in general looking in a map is the same computation complexity as removing, and future operations speed up the more elements are removed, sometimes it is more efficient to remove instead of look, and a default can be needed for the same reasons as you want for look.